home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000057_news@newsmaster….columbia.edu _Thu Sep 24 13:50:34 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA23108
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 24 Sep 1998 13:50:34 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA22905
  7.     for kermit.misc@watsun; Thu, 24 Sep 1998 13:50:33 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Can't get a transfer to work efficiently over a connection with a LanRover in-between.
  12. Date: 24 Sep 1998 17:50:30 GMT
  13. Organization: Columbia University
  14. Lines: 52
  15. Message-ID: <6ue0p6$aq2$1@apakabar.cc.columbia.edu>
  16. References: <6u43q3$fn2$1@ash.prod.itd.earthlink.net> <6u5mis$lnr$1@apakabar.cc.columbia.edu> <6uc3v7$k1j$1@holly.prod.itd.earthlink.net>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9237
  19.  
  20. In article <6uc3v7$k1j$1@holly.prod.itd.earthlink.net>,
  21. Mr. Scott <montgomery@starfleet.org> wrote:
  22. : Allow me to rule out a few things.
  23. : 
  24. : 1. It is not a transparency problem because the transfer works flawlessly
  25. : when packet-length is < 48 (and window size is 1).
  26. :
  27. Agreed.
  28.  
  29. : 2. It is not a flow control problem between our modem and UNIX because both
  30. : (as well as kermit itself) are configured properly: both are configured to
  31. : use RTS/CTS (and kermit); also transfers work at very high speeds with other
  32. : remote hosts with no problem.
  33. : 
  34. But that does not mean it is not a flow control problem.  The fact that
  35. packet lengths > 48 cause a transfer to fail on this connection means that
  36. there a buffer somewhere between your host the destination host that
  37. overflows, and whoever owns that buffer is not flow-controlling its 
  38. transmission peer.
  39.  
  40. : Unfortunately there are no "settings" options at the LanRover prompt that I
  41. : can play with.  They must be configured by the administrator using a
  42. : separate program.
  43. : 
  44. But if transfers work through the same LanRover to other hosts, then it is
  45. most likely a problem in the particular host where the transfer is failing.
  46.  
  47. : This is what we are asking the remote client to check:
  48. : 
  49. : 1. Check that their modem is also using hardware flow control.
  50. : 2. Check that their LanRover machine serial port is using hardware flow
  51. : control.
  52. : 3. Check to see that the LanRover software is configured to work with
  53. : hardware flow contol.
  54. : 
  55. Right.  Wherever there is a junction, hardware flow control should be in force
  56. on both ends of it.
  57.  
  58. : Beyond this, the telnet part of the connection is through TCP/IP and needs
  59. : no flow control configuration, right?
  60. : 
  61. You would think so, but some Telnet servers allow data to be lost when the
  62. controlling (pseudo)terminal is not using flow control.
  63.  
  64. In any case, we should probably move this discussion to email.  If your
  65. investigations do not prove fruitful, we'll need more details about the two
  66. hosts, Kermit versions, settings, etc, and probably also some packet and/or
  67. debug logs.  The Kermit support email address is:
  68.  
  69.   kermit-support@columbia.edu
  70.  
  71. - Frank